🧪 ACID Principles · Interactive Lesson
⚡ One bank transfer. One power outage. What saves your money?
What is ACID?
ACID is a set of four properties that guarantee database transactions are processed reliably.
Think of a transaction as a single operation (like transferring money or booking a flight).
AAtomicity – All or nothing
CConsistency – Valid data only
IIsolation – No chaotic interference
DDurability – Survives catastrophe
Let's explore each one through real scenarios. We'll start with a broken algorithm and see what goes wrong.
Scenario 1: The Broken Transfer
Imagine a simple banking app that transfers $1,000 from Savings to Checking.
Here's the code it runs:
1. Read balance of Savings → $2,000
2. Subtract $1,000 → write $1,000 back to disk
3. Read balance of Checking → $500
4. Add $1,000 → write $1,500 back to disk
5. Send "Success" email
The problem? If the power fails between steps 2 and 4, the money leaves Savings but never arrives in Checking.
Your $1,000 vanishes. The database is in a partial, corrupted state.
🔐 Atomicity — All or Nothing
Atomicity guarantees that a transaction is treated as a single, indivisible unit.
It either completes entirely (every step succeeds) or fails entirely (no steps take effect).
✅ The Fix: If the power fails mid-transfer, Atomicity rolls back the deduction.
Your $1,000 returns to Savings. No partial state. No lost money.
In database terms, this is done using a transaction log — every change is recorded,
and if the transaction doesn't complete, the log is used to undo everything.
Scenario 2: Online Order
Scenario: You buy a $500 laptop from an online store. The system:
- Checks your credit card — $500 available
- Charges your card — deducts $500
- Updates inventory — reduces stock by 1
- Sends order confirmation email
What if the inventory update fails (e.g., database timeout) after your card was charged?
You're out $500 but the store thinks the item is still in stock.
✅ Atomicity saves you: The entire order transaction is atomic — if any step fails (card charge, inventory update, email), all steps are rolled back. Your card isn't charged, and the inventory remains unchanged.
Scenario 3: The Negative Balance
Scenario: A bank has a rule: "Account balances cannot go below $0."
A customer has $500 in their account. They try to withdraw $600.
A naive system might:
- Read balance → $500
- Subtract $600 → write -$100 to disk
- Allow the withdrawal
The problem: The database now allows an invalid state — a negative balance.
This violates the bank's business rule.
🔐 Consistency — Valid Data Only
Consistency ensures that a transaction can only bring the database from one valid state to another.
It enforces all rules: constraints, triggers, foreign keys, and business logic.
✅ The Fix: The database has a CHECK (balance >= 0) constraint.
When you try to withdraw $600 from $500, Consistency aborts the transaction.
The balance stays at $500. No negative balances. No invalid data.
Other examples: UNIQUE constraints (no duplicate emails), FOREIGN KEY constraints (no orphaned records),
and custom business rules (e.g., "an order must have at least one item").
Scenario 4: The Double Booking
Scenario: Two travel agents, Alice and Bob, try to book the very last seat on a flight — at the exact same time.
A naive system might:
- Alice: Reads available seats → 1 seat left
- Bob: Reads available seats → 1 seat left (same time)
- Alice: Books the seat → writes 0 seats left
- Bob: Books the seat → writes 0 seats left (but it's already booked!)
The problem: Both agents successfully booked the same seat.
The system is in a conflict — the seat was double-booked.
🔐 Isolation — No Chaotic Interference
Isolation ensures that concurrent transactions do not interfere with each other.
Each transaction executes as if it were the only transaction running.
✅ The Fix: The database processes transactions sequentially or uses locks.
Alice's transaction runs first — it reads 1 seat, books it, and writes 0.
Bob's transaction starts after Alice commits — it reads 0 seats and fails.
No double-booking.
Isolation levels (like Read Committed or Serializable) control how strictly isolation is enforced —
stricter isolation means less concurrency but more correctness.
Scenario 5: The Power Outage
Scenario: A hospital records a patient's surgery as "Complete" in the database.
The system:
- Writes "Complete" to the database
- Sends a confirmation to the doctor
- 2 seconds later, the server crashes
The problem: If the data was only in memory when the crash happened, the surgery record is lost.
The hospital has no record of the surgery.
🔐 Durability — Survives Catastrophe
Durability guarantees that once a transaction is committed, it stays committed —
even if the system crashes immediately after.
✅ The Fix: The database flushes the data to permanent storage (SSD/disk)
before sending the confirmation. The crash happens after the commit.
When the server reboots, the surgery record is still there.
Durability is typically implemented using a write-ahead log (WAL) —
changes are written to a log on disk first, then applied to the database.
Even if the database crashes, the log can be replayed to recover committed transactions.
🎯 Final Mixed Scenarios
Now, identify which ACID property is being described or violated.
🎉 You've mastered the ACID principles!
Recap:
• Atomicity – All or nothing (rollback on failure)
• Consistency – Rules are enforced (no invalid data)
• Isolation – Concurrent transactions don't interfere
• Durability – Committed data survives crashes
These four guarantees are why we trust databases with our money, flights, and medical records.